Some Java applications and libraries include one or more native libraries. A native library includes functions written in a conventional language that are compiled into machine code. A Java application may include a native library for a number of reasons including performance, access to operating system services which are unavailable to Java code, access to legacy code, and other reasons. Traditionally, native libraries, and often the classes which call them, may be installed on a user's computer before the execution of applications which use the native libraries. Since native libraries are dynamically loaded, by nature they are susceptible to being compromised. It is generally fairly easy to replace a portion of an application, or a library, written in Java. If the native library is compromised, all applications that use that library, whether protected or not, will be compromised as well when the compromised library is used by that application.
Java has a number of mechanisms to protect Java code from inspection and/or from modification. Some frequently used mechanisms may include signed code, cryptographic obfuscation of the Java Archive (“JAR”) file and symbolic obfuscation. Code signing allows a program to verify the origin of any classes it is going to call. Cryptographic obfuscation of the JAR file prevents inspection or modification of the contents without knowledge of the obfuscation key and algorithm, and where a special class loader may be used to deobfuscate the JAR file at runtime. Symbolic obfuscation involves scrambling the symbols of the class files in a JAR file to make it difficult to reverse engineer. While these techniques provide protection to Java code, they work on JAR files, and hence only apply to Java code. Therefore, these techniques do not adequately provide protection to native libraries. While traditional native libraries are typically not obfuscated, they can be signed. However, a Java Virtual Machine does not check signatures on native libraries, nor does it provide a mechanism for Java code to do so.
One traditional means of protecting the integrity of an application is to create a cryptographic binding between its various components. The cryptographic binding allows the caller to verify the origin of the code it is going to call. Optionally, it may also allow the callee to verify the origin of the code which called it. This technique is most often used to create a binding between two native libraries. This technique may also be used to create a binding that protects the integrity of a Java application that contains a native library. However, this method does not adequately prevent the native library from being compromised. In particular, a hacked native library which replaces the original native library may easily inspect the Java code which called it. This means that the keys which are used to create the binding may be easily discovered by the replacement library, allowing the replacement library to successfully impersonate the original library. Furthermore, passing the arguments and return values for each call through a cryptographic process negatively affects the performance of the calls into the native library. Therefore, a traditional cryptographic binding degrades the performance of the application while offering minimal integrity protection.
While maintaining the integrity of any application is important, of particular interest are applications which consume cryptographic services. It is important to preserve the integrity of such applications in order to maintain the confidentiality of the data to which the cryptography is applied. Furthermore, cryptographic technologies have been severely restricted by U.S. and international laws. In accordance with these laws, applications which consume cryptographic services may not be exportable if their cryptographic services can be easily subverted.
An attacker may compromise native libraries used by an application either by replacing the library on the file system, or by preloading a native library that exports the same symbols. For example, a first native library may export a symbol “aaa” and a second native library may also export the symbol “aaa”. If the second native library is loaded before the first native library can be loaded, the Java application that calls for “aaa” will call the “aaa” symbol in the second native library instead of the “aaa” symbol in the first native library because Java uses the first symbol it sees of a particular name. Thus, the second native library (i.e., a rogue native library) will be called instead of the intended first native library.
One reason why developers use Java is that Java applications frequently do not need to be installed on a user's computer. They may be downloaded from a network as needed. However, if a Java application uses a native library, that application, or a portion of it typically must be installed. This encumbers the deployment of the application and increases the risk of native library being compromised.
These and other drawbacks exist with current systems.